Subject: RE: Proposed ADC requirements Re: DATCON/DCCORP/ColinD

From: "Hildebrand, Jeff" <[email-masked]>
Date: Wed, 27 Apr 94 05:09:00 PDT

! My response,
Jeff
 ----------
From: DATCON/DCCORP/ColinD
To: ciw-sig-adc
Subject: RE: Proposed ADC requirements
Date: Tuesday, April 26, 1994 3:52PM

Sorry about the delay, my comments \ additions are mixed into the text.

Regards,

Colin.

(Data Connection  1-703-715-4914)
 ----------
From: "Hildebrand, Jeff"  <[email-masked]>
To: ciw data conversion  <[email-masked]>
Subject: Proposed ADC requirements
Date: 20 April 1994 08:24

To: CIW ADC SIG
Subject: ADC Requirements

I believe there is general recognition that CPIC must
aid in the encoding and decoding of user data, and
that this should be done outside the application program.

In order to facilitate the creation of a viable solution
 the requirements that must be met should be
explicitly stated.  The requirements presented below  are
a proposed set and designed to foster discussion.
  -----------              ----------

         ADC Requirements

1. The solution must fully support both LU 6.2 and OSI TP.
   A. For LU 6.2 this means implementing a mechanism that
      supports the LU 6.2 mapper architectural construct.
   B. For OSI TP it means fully exploiting the U-ASE by
      allowing it to encode, decode, and possibly perform
      other transformations on user data.
> Jeff, what other transformations did you have in mind?

2. The solution must support both 'regular' data and
   initialization data.
3. It need not deal with expedited data.
> Is initialization data a definite requirement? I would lean
> towards only converting normal data. This leaves more
> flexibility in how the map name is passed by the
> application and  I'm also not clear if mapping of PIP data
> is part of the current LU 6.2 model.

! Initialization data is a definite requirement OSI requirement.
! Vendors are expecting to see the following PDU series:
!
!    TP-BEGIN-DIALOGUE (initialization data included)
!    TP-PREPARE
!    TP-COMMIT
!
! These would all be concatenated into one physical send.

4. It must be backwards compatible.  That is allow
   existing programs to use these new facilities with
   out modifying existing code.
> I agree we shouldn't break current apps, but I am not
> clear how an app sending data can take advantage of
> data mapping without code changes.
!
! Side information can be used to set the MAP_NAME.  A program
! need not issue an extract if it knows what it is receiving.
! So existing programs can use the new capability without modifcation
!

5. Avoid new send and receive commands.
> If there is no requirement for initialization data, I would
> suggest that new commands are the correct approach,
> so I disagree with this point.

6. Allow the more skilled programmer to support the
   least skilled programmer without having to
   deal with other face to face.  The  more skilled
   can build ADC mechanisms that a wide audience of
   less skilled programmers can 'blindly' use.
> Yes.

7. The mechanism must be invisible to the CPIC
    application programmer.
> Yes

8. The ADC mechanism's only interface with the
    application program is to send/receive a data buffer
    and a MAP_NAME  identifying the contents of the
    buffer.
> Yes

9. The data being sent must be 'flatened' - All pointers
    resolved, etc.
> Yes, but as a caveat this means the mapper needs to
> be near the CPI-C interface else it might be impossible
> to get access to the required memory.
! Probably, very true.

I would like to get your views and suggested requirements in the
next 4 or 5 work days.

Regards,
Jeff

[email-masked]
206 865-4893